home *** CD-ROM | disk | FTP | other *** search
/ Just Call Me Internet / Just Call Me Internet.iso / patches / hsmoda07 / hsm_doku / mfp_x.txt < prev    next >
Text File  |  1996-04-08  |  26KB  |  608 lines

  1. MFP.PRG, MFP_TT.PRG, MFP_FALC.PRG, MFP_BAST.PRG
  2. ***********************************************
  3.  
  4. (Note for the English reading people: The English version is appended on 
  5. the German, look for it!)
  6.  
  7. !!! Wichtiges Neues selbst bersetzt. Harun. !!!
  8.  
  9. Dies sind Treiber fr die mit MFPs (z.B. Schaltkreis MC68901 von 
  10. Motorola) ausgestatteten seriellen Schnittstellen der Ataris. Sie 
  11. funktionieren zusammen mit DRVIN.PRG oder einem gleichwertigen Ersatz. 
  12. Einfhrende Bemerkungen finden sich in 1_README.TXT.
  13.  
  14.  
  15. Allgemeines
  16. -----------
  17. Momentan besitzen alle MFP*.PRG die gleichen Einstellm”glichkeiten durch 
  18. SETTER.
  19.  
  20. Der serielle Teil des MFP, die USART, ist nicht ganz so leistungsf„hig wie 
  21. beim SCC. Dadurch sind die MFP-Schnittstellen gegen Zeitknappheit der CPU 
  22. allergischer als die SCCs und reagieren leichter mit Zeichenverlusten.
  23.  
  24.  
  25. MFP.PRG
  26. -------
  27. MFP.PRG ist fr den sogenannten ST-MFP gedacht, der ab Adresse $FFFFFA01 
  28. liegt und in ST, STE, MegaST, MegaSTE, TT, Stacy und STBook vorhanden ist. 
  29. Im Falcon ist dieser MFP ebenfalls vorhanden, der USART-Teil aber anders 
  30. (=nicht) benutzt, so daž MFP.PRG NICHT fr den Falcon ist. Dieser Treiber 
  31. tr„gt sich als BIOS-Ger„t 6 und mit dem Namen "MODEM1" ein.
  32.  
  33.  
  34. MFP_TT.PRG
  35. ----------
  36. MFP_TT.PRG untersttzt den sogenannten TT-MFP ab Adresse $FFFFFA81, der 
  37. bisher nur im TT vorkommt. Der Treiber tr„gt sich als BIOS-Ger„t 8 und mit 
  38. dem Namen "SERIAL1" ein.
  39.  
  40.  
  41. MFP_FALC.PRG
  42. ------------
  43. MFP_FALC.PRG ist fr die bastelfreudigen Falcon-Besitzer gedacht, die die 
  44. von Atari nicht herausgefhrte serielle Schnittstelle des MFP 
  45. herausgefhrt haben. Der Treiber tr„gt sich als BIOS-Ger„t 6 und mit dem 
  46. Namen "MODEM1" ein.
  47.  
  48. Hier noch eine Mail, die ich aus der Mausgruppe Atari.Hard gefischt habe, 
  49. bezglich Herausfhrung der MFP-Schnittstelle des Falcon:
  50.  
  51. -------------------Mailanfang-------------------------
  52. Gruppe: Atari.Hard
  53. #A5003@WI2 (So 26.09.1993, 08:18) MFP-Serielle im Falcon
  54.  
  55. Von: Martin Liebeck @ WI2
  56. Wg.: MFP-Serielle im Falcon
  57. Von : Martin Liebeck @ WI2 (Sa, 25.09.93 09:55)
  58.  
  59. Ein Tip fr Alle, die gerne eine zweite Serielle an ihrem Falcon h„tten:
  60.  
  61. die MFP-Serielle wird unter Port Nr. 6 vom TOS (4.01) untersttzt und kann als
  62. Dreidrahtschnittstelle verwendet werden. Atari hat hier wohl lediglich die
  63. Buchse und die Treiber gespart...
  64.  
  65. RXD liegt an Pin 10 des MFP und ist nach Masse gelegt. In meinem Layout wird
  66. hierzu eine ca. 3mm lange Leiterbahn auf der Platinenoberseite von Pin 10 zu
  67. einer Durchkontaktierung nach Masse verwendet. Diese muá vorsichtig (nicht zu
  68. tief, Multilayer!) unterbrochen werden. TXD bekommt man an Pin 9 des MFP.
  69.  
  70. Ich habe noch mit einer 1488/1489 Kombination auf RS232-Pegel gewandelt und die
  71. Pins 1 und 3 von Midi-in als Verbindung zur Auáenwelt verwendet.
  72.  
  73. Garantie, insbesondere fr ruinierte Boards, bernehme ich natrlich keine. Ich
  74. weiá auch nicht, wie h”here TOS-Versionen als 4.01 mit dem MFP verfahren. Am
  75. Besten erst mal an Pin 9 messen, ob ein Signal kommt. Viel Spaá beim l”ten, es
  76. lohnt sich.
  77.  
  78. Gruá Martin.
  79. ---------------Mailende-----------------
  80.  
  81.  
  82. MFP_BAST.PRG
  83. ------------
  84. MFP_BAST.PRG ist fr die Bastler gedacht, die sich einen TT-kompatiblen 
  85. zweiten MFP in einen nicht-TT eingebaut haben. Der Treiber installiert 
  86. sich mit dem Namen "SERIAL1" und der ersten freien BIOS-Ger„tenummer.
  87.  
  88. Der Bastel-MFP wird vom Treiber als vollwertige Schnittstelle mit 
  89. Steuerleitungen betrachtet. Die Leitungen werden m”glichst 
  90. ST-MFP-kompatibel vom GPIP-Register des Bastel-MFP realisiert. Es gilt 
  91. folgende Belegung:
  92. IO1: DCD, Eingang (wie ST-MFP)
  93. IO2: CTS, Eingang (wie ST-MFP)
  94. IO3: RTS, Ausgang (beim ST-MFP ber PSG)
  95. IO4: DTR, Ausgang (beim ST-MFP ber PSG)
  96. IO6: RI,  Eingang (wie ST-MFP)
  97.  
  98.  
  99. Im Folgenden geht es haupts„chlich um MFP.PRG:
  100.  
  101.  
  102.  
  103. Dies ist ein Software-Beschleuniger und Patch fr die serielle 
  104. Schnittstelle Modem1 der Atari-Computer. Es beseitigt nicht nur den auch 
  105. im TOS2.06/3.06 noch vorhandenen RTS/CTS-Handshakefehler, sondern erh”ht 
  106. durch seine optimierten Routinen die m”gliche šbertragungsrate wesentlich. 
  107. Sp„testens wenn Fragen auftreten sollte man diesen Text komplett lesen und 
  108. erst danach seiner Umwelt oder mir die verbliebenen Fragen stellen. Bei 
  109. Updates und Zeitmangel zuerst einen Blick nach ganz hinten, Abschnitt 
  110. "Versionen"!
  111.  
  112.  
  113. Kompatibilit„t zu HSMODEM1
  114. --------------------------
  115. Wird MFP.PRG als letzter oder als einziger Treiber gestartet, so sollten 
  116. alle Programme, die mit den HSMODEM1-Versionen funktioniert haben, auch 
  117. mit diesen Treibern laufen, wenigstens wie bisher auf MODEM1.
  118.  
  119.  
  120. Einsatzm”glichkeiten, Voraussetzungen, u.v.m.
  121. ---------------------------------------------
  122. Mag!X
  123. Versionen ab 2.00 dieses multitaskf„higen Betriebssystems (es ist im 
  124. Gegensatz zum aktuellen MultiTOS nicht nur ein Aufsatz und wesentlich 
  125. schneller) haben korrekte Routinen zur Schnittstellen-Bedienung. Die 
  126. entsprechenden GEMDOS-Funktionen fehlen in Mag!X 2.00 aber noch. 
  127. Interessant ist das Mag!X-Multitasking auf 8MHz-STs bei 38400Bd-Empfang: 
  128. (mit einem NVDI ab Version 2.50 vom 28.10.1993) Man kann im Vordergrund 
  129. mit der Maus wirtschaften und einen Text schreiben (getestet mit Everest), 
  130. w„hrend im Hintergrund GSZRZ 3.5 fehlerfrei empf„ngt. Mit Mag!X ab Version 
  131. 2.00 sollte man die Interruptroutinenmodifikation im MFP.PRG abschalten, 
  132. da Mag!X bereits modifizierte Timerroutinen hat. Wenn MFP.PRG da noch 
  133. etwas einh„ngt, wird es ein bižchen langsamer.
  134.  
  135. Diese Treiber sind ein Ersatz fr andere Patches (nicht nur fr Modem1), 
  136. wie z.B. RS232ENC oder TURBOCTS.
  137.  
  138. Die Schnittstelle Modem1 kann ohne Zusatzhardware maximal 19200Bd 
  139. erreichen. Daran „ndert auch MFP.PRG nichts. Es ersetzt aber die langsamen 
  140. und zum Teil fehlerhaften Routinen des TOS durch schnelle und hoffentlich 
  141. fehlerfreie. Mit Zusatzhardware, wie (dem von mir entwickelten) RSVE, 
  142. RS-Speed (von Stephan Skrodzki) oder anderen k”nnen h”here Datenraten 
  143. realisiert werden. Z.B. erlaubt RSVE auch die Einstellung von 38400, 57600 
  144. und 115200Bd. MFP.PRG sorgt dann im Rahmen der Hardware-M”glichkeiten fr 
  145. einen wesentlich h”heren Datendurchsatz (cps-Rate). Der komplette Bauplan 
  146. fr RSVE liegt als RSVE.LZH in Mailboxen, auf jeden Fall in der Maus 
  147. Berlin (@B). Die Fertigversion von RSVE gibt es direkt bei mir.
  148.  
  149. Wenn jemand meint, allein mit Software Modem1 mit mehr als 19200Bd 
  150. betreiben zu k”nnen: Das geht im Synchronbetrieb des MFP (Abschalten der 
  151. Taktteilung /16). Dabei ist eine fehlerfreie Funktion aber ausschliežlich 
  152. beim Senden m”glich, NICHT beim Empfang.
  153.  
  154. Ich arbeite mit einem 8MHz ST, ohne CPU-Beschleuniger. Ich halte wenig 
  155. davon, immer neue und schnellere Computer zu kaufen und diese durch lahme 
  156. Software bis zum Stillstand zu bremsen. Das TOS ist eine lahme Software, 
  157. kein Wunder, es ist inklusive der Interruptroutinen in C programmiert (es 
  158. sieht so aus). MultiTOS ist eine noch gr”žere Systembremse. Mag!X ist 
  159. genau das Gegenteil.
  160.  
  161.  
  162. Fehler anderer Programme
  163. ------------------------
  164. Mit Rufus 1.11rel9 steht der Rechner nach dem Auflegen einiger Modems (RXD 
  165. und TXD leuchten beide, nichts geht mehr). Abhilfe: Rufus 1.20 oder neuer 
  166. benutzen.
  167.  
  168.  
  169. Wie schnell geht es?
  170. --------------------
  171. Das Problem bei einer seriellen šbertragung mit einer bestimmten 
  172. Geschwindigkeit (hier in Baud angegeben) ist nicht das Senden der Zeichen, 
  173. sondern deren Empfang. Der MFP puffert nur ein empfangenes Zeichen und 
  174. meldet es der CPU per Interrupt. Die CPU muž dieses Zeichen fr eine 
  175. fehlerfreie šbertragung aus dem MFP abholen, bevor er das n„chste Zeichen 
  176. komplett empfangen hat. Wenn ich sage, der Betrieb bei ... ist zuverl„ssig, 
  177. so bedeutet dies, daž die CPU bei der maximal m”glichen 
  178. Empfangs-Zeichendichte (keine Pause zwischen Stoppbit des vorigen und 
  179. Startbit des folgenden Zeichens) jedes Zeichen rechtzeitig abholt.
  180.  
  181. Ein 8MHz ST (RSVE eingebaut) kann mit TOS und HSMODEM1 eine fehlerfreie 
  182. Datenbertragung mit 38400Bd realisieren. Mit einem HSMODEM1 ab dem 
  183. 21.05.1993 funktioniert auch der Empfang (Senden sowieso) mit 57600Bd auf 
  184. 8MHz STs, wenn die Interruptroutinenmodifikation (FASTINT) eingeschaltet 
  185. ist.
  186.  
  187. Derzeit erreicht ein 8MHz ST mit GSZRZ Version 3.3 von Michael Ziegler bei 
  188. einer ZMODEM-šbertragung und 38400Bd mehr als 3600cps, wenn NVDI 
  189. installiert und der Blitter ausgeschaltet ist. Ohne NVDI sind es etwa 
  190. 300cps weniger, da GSZRZ lange an seiner Dialogbox zeichnen l„žt. Den 
  191. Blitter kann man in den meisten F„llen auch zugeschaltet lassen. Sollten 
  192. aber Empfangsfehler auftreten, dann den Blitter abschalten. 
  193. ZMODEM-šbertragung ber die Filefunktionen bringt mit einem GSZRZ ab 3.5 
  194. mehr als 5400cps bei 57600Bd.
  195.  
  196. Die angegebenen Datenraten gelten fr direkte Rechnerkopplung. Fr langsame 
  197. Modems und schlechte Telefonleitungen sind die Treiber nicht verantwortlich! 
  198. Zyxels k”nnen bei 16800zyx/v42bis und ASCII-Texten 3800cps erreichen, 
  199. Zyxel+ bei 19200zyx noch mehr. Andere 14400/v42bis-Modems liegen bei etwa 
  200. 3300cps.
  201.  
  202. Die von mir entwickelte Hardware ST_ESCC hat auch bei 115200Bd noch 
  203. keinerlei Probleme, selbst bei Tastaturtippen unter normalem TOS, da sie 
  204. ber einen 8 Byte grožen Empfangs-FIFO verfgt. Sie beschleunigt aber 
  205. nicht MODEM1, sondern realisiert zwei zus„tzliche schnelle Serielle.
  206.  
  207.  
  208. 57600Bd auf 8MHz und 16MHz 68000er ber _MODEM1_
  209. ------------------------------------------------
  210. 57600Bd ist fr Modem1 auf (Mega)ST(E) die magische Grenze, die 
  211. auch nur mit leichten Modifikationen im TOS erreicht wird. 115200Bd werden 
  212. wohl auch in Zukunft nur im Polling und nicht im Interruptbetrieb m”glich 
  213. sein.
  214.  
  215. Bei mir funktionieren 57600Bd auf einem 8MHz-ST mit TOS2.06. Ich bin mir 
  216. aber nicht sicher, ob es auch mit anderen („lteren) TOS-Versionen 
  217. funktioniert.
  218.  
  219. Da ich immer wieder gefragt werde, wie man 57600 fehlerfrei erreicht: 
  220. Blitter aus, keine DMA-Zugriffe w„hrend Dateibertragung (in den Filepuffer 
  221. des ZMODEMs muž bei Empfang das ganze File passen), keine Joysticks mit 
  222. Autofire oder DCF-Uhren am Joyport. Dann testweise alle residenten 
  223. Programme und ACCs entfernen und nur die wieder benutzen, die nicht st”ren.
  224.  
  225.  
  226. Die Konfiguration
  227. -----------------
  228. Die Konfiguration erfolgt durch das SETTER.TTP. Zur Bedienung siehe 
  229. SETTER.TXT.
  230.  
  231. RSVE:
  232. MFP.PRG kann den Cookie RSVE anlegen und macht damit das RSVE_SET.PRG 
  233. berflssig. Dieser Cookie sollte nur noch fr alte Programme interessant 
  234. sein, die ausschliežlich an ihm das Vorhandensein der Hardware RSVE 
  235. erkennen. Aužerdem werden die bei RSVE (und RS_Speed) m”glichen hohen 
  236. Baudraten den Fcntl-TIOC?BAUD-Funktionen mitgeteilt (anstelle der 
  237. 150/134/110).
  238.  
  239. REPL:
  240. MFP.PRG kann Baudraten umlegen. Dies ist nur zusammen mit RSVE oder 
  241. RS-Speed ntzlich, falls Programme weder RSVE/RS_Speed kennen noch 
  242. 110/134/150Bd einstellen k”nnen. So kann man die Einschaltung von 38400Bd, 
  243. die bei ahnungslosen Programmen normalerweise durch Einstellen von 110Bd 
  244. erfolgt, auf das Einstellen von 19200Bd legen. Man gibt (wie es SETTER 
  245. beschreibt) zuerst die zu ersetzende alte Baudrate und dann (auf den 
  246. n„chsten Platz) die dort hinzulegende hohe Rate an, und zwar ganz exakt. 
  247. Der erste als "ungltig" gekennzeichnete Platz beendet die Suche nach 
  248. Umbelegungen. Will man nichts umlegen, gibt man berall "u" an. Die 
  249. Baudraten 115200/57600/38400 liegen mit der Hardware RSVE ohnehin auf 
  250. 150/134/110, sie dorthin umzulegen ist sinnlos. Die Umlegungen sind fr 
  251. Programme unsichtbar und erscheinen nicht in den Fcntl TIOC?BAUD.
  252.  
  253. DTR: (nur bei MFP.PRG)
  254. Das DTR(Data Terminal Ready)-Signal wird beim Start dieses Treibers 
  255. einmalig auf den hier angegebenen Wert gesetzt. Eine Aktivierung mit "Ja" 
  256. entspricht der Arbeitsweise des TOS, eine Deaktivierung mit "Nein" 
  257. verhindert das "ungefragte" Abheben eines entsprechend konfigurierten 
  258. Modems.
  259.  
  260. RBL:
  261. Wenn man hiermit nichts anzufangen weiž, einfach 256 einstellen. Hier wird 
  262. die Empfangspufferl„nge in Byte eingestellt. Sie darf maximal 65534 und 
  263. minimal 16 betragen. Werte aužerhalb dieses Bereiches werden auf den 
  264. Standardwert von 256 gesetzt. Die L„nge wird auf eine gerade Zahl 
  265. abgerundet. Die Wassermarken werden generell auf 1/4 (low water mark) und 
  266. 3/4 (high water mark) gesetzt.
  267.  
  268. TBL:
  269. Wie RBL, aber diesmal die Sendepufferl„nge.
  270.  
  271.  
  272. Speeder-Erkennung (RSVE, RSVEChip u.a.)
  273. ---------------------------------------
  274. Der Treiber versucht automatisch zu erkennen, ob ein 
  275. Schnittstellenbeschleuniger installiert ist. Das Ergebnis seiner 
  276. Erkundungen wird bei der Installation ausgegeben, momentan in der dritten 
  277. Zeile direkt unter dem "(C)...". Dies ist jedoch kein intensiver 
  278. MFP-UART-Test, so daž ein defekter MFP oder fehlerhafte Verbindungen nicht 
  279. zwangsl„ufig erkannt werden mssen oder auch zu anderen Ausgaben als 
  280. "...defective???" fhren k”nnen.
  281.  
  282. Es sind folgende Meldungen m”glich:
  283.  
  284. "MFP-UART defective???"
  285. Der UART des MFP verhielt sich beim Test mit 1200 bps seltsam. Die reale 
  286. Datenrate liegt scheinbar weit unter 1200 bps. M”glicherweise k”nnten 
  287. irgendwelche mir unbekannten Speeder diese Ausgabe erzeugen, dann bitte 
  288. Nachricht an mich. Wahrscheinlicher ist ein Defekt des MFP oder der 
  289. Verbindungen zwischen den Pins TDO und TC.
  290.  
  291. "MFP without additions."
  292. Es wurde ein normaler MFP vorgefunden, ohne Speeder-Hardware, der sich bei 
  293. 1200 bps und 110 bps normal verhielt.
  294.  
  295. "Fixed speedup or Analog PLL."
  296. Vermutlich wurde der MFP-UART durch eine feste externe Takteinspeisung auf 
  297. 38400 bps oder mehr eingestellt oder eine PLL multipliziert den UART-Takt. 
  298. Jedenfalls lag die reale Datenrate beim Test mit 1200 bps weit ber diesem 
  299. Wert. ### Momentan habe ich keine Lust, den Typ des Speeders n„her zu 
  300. ergrnden. ###
  301.  
  302. "RSVE or compatible found."
  303. Vermutlich ist ein RSVE oder RSSpeed oder ein kompatibler Baudratenwandler 
  304. installiert. Der Test bei 1200 bps lief normal ab, 110 bps waren jedoch 
  305. stark beschleunigt (= umgewandelt).
  306.  
  307. "RSVEChip found."
  308. Meine neueste Bastelei, der RSVEChip, wurde erkannt. 1200 bps waren 
  309. normal, 110 bps wurden jedoch auf einen RSVEChip-typischen Wert gewandelt.
  310.  
  311. Wenn irgend ein Beschleuniger erkannt wurde, so werden automatisch 38400, 
  312. 57600 und 115200 bps fr die GEMDOS-Funktionen zus„tzlich eingetragen. 
  313. Sollte jemand einen Beschleuniger haben, der nicht erkannt wurde, diese 
  314. hohen GEMDOS-bps-Raten aber fr ein Programm brauchen, so soll er den 
  315. Konfig-Punkt "RSVE" mit "Ja" beantworten!
  316.  
  317. Diese Funktion hat mich doch einige Zeit des Nachdenkens gekostet, bis ich 
  318. auf die hier verwendete Realisierung gekommen bin, die die reale 
  319. Geschwindigkeit (bps-Rate) mižt ohne dabei auf dem Ausgang TXD der 
  320. Schnittstelle Mll auszugeben.
  321.  
  322.  
  323. M”gliche Probleme
  324. -----------------
  325. Lange DMA-Zugriffe k”nnen beim Empfang zu Datenverlusten fhren. Ebenfalls 
  326. kritisch sind lange Verweilzeiten der CPU in einem Interruptpriorit„tslevel 
  327. gr”žer als 5.
  328.  
  329. Auf 8MHz STs ohne Mag!X >2.00 und ohne neues NVDI (mindestens Version 2.50 
  330. vom 28.10.1993): Bei mehr als 9600Bd Finger weg von Maus und Tastatur, 
  331. w„hrend GSZRZ empf„ngt. Sonst gibt es ein paar šbertragungsfehler (bei 
  332. MODEM1). Genauso k”nnen ein paar Zeichen verloren gehen, wenn im 
  333. Terminalprogramm gerade ein Text ankommt und der User die Tastatur oder 
  334. Maus bearbeitet.
  335.  
  336. Abspeichern empfangener Daten unter GSZRZ w„hrend des Empfangs fhrt bis 
  337. 38400Bd meist nicht zu Fehlern.
  338.  
  339. Man kann den Blitter so programmieren, daž er die CPU zu lange blockiert. 
  340. Das TOS und NVDI tun dies anscheinend nicht. Wenn Fehler beim Empfang mit 
  341. >= 38400Bd auftreten, erst mal mit abgeschaltetem Blitter probieren.
  342.  
  343. Es gibt einige ACCs und residente (AUTO-Ordner-)Programme, die irgendwelche 
  344. Interrupts umlegen und das System zu lange blockieren. Im Zweifelsfalle 
  345. einzeln rauswerfen und testen.
  346.  
  347. MiNT und besonders MultiTOS sind allgemeine Systembremsen, die sich 
  348. besonders auf 8MHz-Rechnern bemerkbar machen. Mag!X finde ich pers”nlich 
  349. wesentlich besser, da es wesentlich schneller ist.
  350.  
  351. DCF_TIME von Ralf Zimmermann @WI2 sollte in der Version 1.2 oder h”her 
  352. verwendet werden. Aber nur die Abfrage ber den RingIndicator macht keine 
  353. Probleme bei 57600Bd, ber den Joyport gibt es sekndlich Žrger.
  354.  
  355. QFAX frižt sehr viel Rechenzeit und sollte bei Problemen zuerst entfernt 
  356. (nicht nur abgeschaltet) werden.
  357.  
  358.  
  359. Funktion des ...
  360. ----------------
  361. Siehe DRVIN.TXT, RSVE_COO.TXT, SERSOFST.TXT.
  362.  
  363.  
  364. Versionen
  365. ---------
  366. Diese Daten gelten fr alle MFP*.PRG, wenn nicht anders vermerkt.
  367.  
  368. 1993-11-21  erste Ver”ffentlichung
  369. 1993-11-23  bleibt auch bei Installationsfehler resident allerdings passen 
  370. dann ser. Interruptroutinen und Bco* nicht zusammen. (besser als 
  371. Totalabsturz)
  372. 1993-12-15  bei den MFP*.PRG ohne Hardwarehandshakeleitungen: TIOCSFLAGS 
  373. verbietet RTS/CTS durch Fehlermeldung ERANGE. In diesem Fall werden die 
  374. Einstellungen nicht gesetzt!
  375. 1994-01-01  Fcntl TIONOTSEND und TIOCFLUSH implementiert, DTR-Signal 
  376. nutzerdefiniert bei MFP.PRG, Puffergr”žen durch Nutzer einstellbar
  377. 1994-03-27  Fcntl TIOCFLUSH Nr.1,2,3 gehen jetzt endlich
  378. 1994-04-07  Empfangspuffer-High-Water-Mark korrekt initialisiert
  379. 1994-06-17  ACHTUNG! Installationsblock an MagiC3 angepažt. Nur noch 
  380. Treiber und DRVIN von 1994-06-17 oder jnger zusammen verwenden. Versionen 
  381. vor dem 1994-06-17 laufen nicht mit denen ab 1994-06-17 zusammen.
  382. 1994-08-18  FASTINT verschoben nach DRVIN.PRG
  383. 1994-08-25  Erg„nzung in bconout fr MC68040 (Medusa)
  384. 1994-09-27  an der Senderegister-leer Auswertung gebastelt (Medusa)
  385. 1994-10-03  einige Fehler in MFP_TT raus (sprach ST-MFP an), TIOCCTLGET 
  386. ge„ndert (CTS erfragbar, DTR wird auch bei *GET geliefert (RTS auch, 
  387. aber noch versteckt, da in *MAP nicht gesetzt)), Byte4Bit0 im RSVF, 
  388. MFP_BAST realisiert
  389. 1994-10-24  TIOCM_BRK und TIOCM_RER(overrun, parity, frame error zusammen) 
  390. ber Fcntl TIOCCTLGET
  391. 1995-01-03  schnelle Bconout-Parameterbergabe ge„ndert 
  392. (und MAPT_APP/MAPT_OVE Funktiosnummer), Cache-Flush fr 68040, optimiert
  393. 1995-02-02  neuer Fehler bei Ring-Indicator-Abfrage in MFP.PRG und 
  394. MFP_BAST.PRG wieder beseitigt
  395. 1995-06-26  Fehler beseitigt, der nach Frame- oder Parity-Error 
  396. den Empfang blockierte (bis zum n„chsten Baudratenwechsel)
  397. 1996-03-28  Fr 75 und 50 werden nun wirklich 75 und 50 eingestellt, da 
  398. wohl sowieso niemand diesen TOS-Fehler brauchte.
  399. 1996-04-08  Konfig HISP raus, automatische Speedererkennung, auch RSVEChip
  400.  
  401. Harun Scheutzow, 21.11.1993 und sp„ter
  402. (Harun_Scheutzow@b.maus.de)
  403.  
  404.  
  405.  
  406.  
  407. MFP.PRG, MFP_TT.PRG, MFP_FALC.PRG, MFP_BAST.PRG
  408. ***********************************************
  409.  
  410. (The most important parts translated from German to English on 1994-01-08 
  411. by Harun Scheutzow. I have no time for translating all. If anybody 
  412. translates the remaining parts, I'm very interested in getting the result 
  413. for including it in the next version of this package. My native language 
  414. is German, I think a person whos native language is English would do a 
  415. much better translation. Thanks! (Send only mails smaller than 16kbyte to 
  416. my email address.))
  417.  
  418. These are drivers for the interfaces realized by MFPs (eg IC MC68901 
  419. manufactured by Motorola). They work together with DRVIN.PRG or an 
  420. equivalent replacement. 1_README.TXT contains an introduction.
  421.  
  422.  
  423. The general
  424. -----------
  425. Currently all MFP*.PRG have the same configuration possibilities.
  426.  
  427. The serial part of the MFP, the USART, is not as powerful as the one of 
  428. the SCC. That's why the MFP interfaces are more allergic against high CPU 
  429. load and lose more easy characters.
  430.  
  431.  
  432. MFP.PRG
  433. -------
  434. MFP.PRG is made for the so called ST-MFP, which lays from address 
  435. $FFFFFA01 up in every ST, STE, MegaST, MegaSTE, TT, Stacy and STBook. The 
  436. Falcon has this MFP too, but the USART-part is used in an other way (not 
  437. used). MFP.PRG is not for the Falcon. This driver provides the BIOS-device 
  438. 6 and the name "MODEM1".
  439.  
  440.  
  441. MFP_TT.PRG
  442. ----------
  443. MFP_TT.PRG supports the so called TT-MFP form address $FFFFFA81 up, 
  444. contained only in the TT until now. This driver provides the BIOS-device 8 
  445. and the name "SERIAL1".
  446.  
  447.  
  448. MFP_FALC.PRG
  449. ------------
  450. MFP_FALC.PRG is made for the users who modified their Falcon by drawing 
  451. out the serial interface of the MFP, unused in the original state. The 
  452. driver provides the BIOS-device 6 and the name "MODEM1".
  453.  
  454. (-- Mail is only in the German part --)
  455.  
  456.  
  457. MFP_BAST.PRG
  458. ------------
  459. MFP_BAST.PRG is intended for people who soldered a TT-compatible second 
  460. MFP in a non-TT computer. The driver installs itself with the name 
  461. "SERIAL1" and the first empty BIOS device number.
  462.  
  463. The driver takes this added MFP as a full featured RS232-interface with 
  464. control lines. The control lines are realized as ST-MFP-compatible as 
  465. possible by the GPIP-register. The assignment is as follows:
  466. IO1: DCD, input (as ST-MFP)
  467. IO2: CTS, input (as ST-MFP)
  468. IO3: RTS, output (at ST-MFP realized by PSG)
  469. IO4: DTR, output (at ST-MFP realized by PSG)
  470. IO6: RI,  input (as ST-MFP)
  471.  
  472.  
  473.  
  474. In the following I will describe principal the MFP.PRG:
  475.  
  476.  
  477.  
  478. This is a software speeder and patch for the interface MODEM1 of the Atari 
  479. computer. It removes not only the RTS/CTS-handshake bugs contained in the 
  480. TOS2.06/3.06 too, but increases with its optimized routines the possible 
  481. transfer rate.
  482. (-- something untranslated --)
  483.  
  484.  
  485. Compatibility to HSMODEM1
  486. -------------------------
  487. If MFP.PRG is loaded as the only one or the last driver, all programs 
  488. which run with HSMODEM1 should run with these driver to (on MODEM1).
  489.  
  490.  
  491. Suppositions, ...
  492. -----------------
  493. Mag!X
  494. Versions from 2.00 up of these multitask operating system (it is in 
  495. opposite to the current MTOS not only an addition to TOS) have correct 
  496. routines for the serial interfaces. The corresponding GEMDOS-functions 
  497. are absent in version 2.00. The Mag!X-multitasking on an 8MHz-ST during 
  498. 38400Bd-receive (eg ZMODEM) is very nice (with a NVDI form Version 2.50 
  499. form 28.10.1993 up): It is possible to work in the foreground with 
  500. keyboard and mouse (eg in a text editor, tested with Everest) while in the 
  501. background the ZMODEM-receive (GSZRZ) runs without any errors. Such 
  502. performance became true by intelligent programming. With Mag!X from 
  503. version 2.00 up the timer interrupt routine modification should be 
  504. switched off because Mag!X has its own nice routines.
  505.  
  506. These drivers are a replacement for other patches (not only for MODEM1), 
  507. eg RS232ENC or TURBOCTS.
  508.  
  509. The interface MODEM1 runs without additional hardware with a maximum of 
  510. 19200Bd. MFP.PRG can not change this. But it replaces the slow and in part 
  511. buggy routines of the TOS by fast and (I hope) error free ones. With 
  512. additional hardware as the RSVE (developed by me), or as RS-Speed (by 
  513. Stephan Skrodzki) or others baud rates higher than 19200 are provided. 
  514. RSVE allows 38400, 57600 and 115200Bd. MFP.PRG realizes in the range of 
  515. the hardware possibilities (CPU speed, MODEM speed, ...) for a higher 
  516. thruput. The complete documentation of RSVE lays in some mailboxes.
  517.  
  518. It is impossible to set the MODEM1 only by software to more than 19200Bd 
  519. in the _asynchron_ mode.
  520.  
  521. (-- something untranslated --)
  522.  
  523.  
  524. Bugs of other programs
  525. ----------------------
  526. (-- something untranslated --)
  527.  
  528.  
  529. How fast it can run?
  530. --------------------
  531. The problem of the serial transfer with a given speed (measured in Baud) 
  532. is not the transmission of the characters but their reception.
  533. (-- something untranslated --)
  534.  
  535.  
  536. 57600Bd on 8MHz and 16MHz 68000 CPUs on MODEM1
  537. ----------------------------------------------
  538. 57600Bd is the magic border of MODEM1 on (Mega)ST(E) which is achieved 
  539. only by small modifications in TOS (or by Mag!X). 115200Bd seem to be 
  540. possible by polling only.
  541.  
  542. (-- something untranslated --)
  543.  
  544.  
  545. Configuration
  546. -------------
  547. The configuration is done by using SETTER.TTP.
  548.  
  549. Because the explainations in the drivers are German I added an 
  550. abbreviation.
  551.  
  552. RSVE:
  553. (Only for users of the RSVE-hardware. Otherwise answer with Nein.) MFP.PRG 
  554. can create the cookie RSVE making the RSVE_SET.PRG unnecessary. The 
  555. function of HISP is done automatically.
  556.  
  557. HISP:
  558. This setting enables the high baud rates possible with RSVE and RS_Speed 
  559. in the Fcntl-TIOC?BAUD-functions instead of 150/134/110.
  560.  
  561. REPL:
  562. MFP.PRG can replace baud rates. This is useful only with RSVE or 
  563. RS-Speed if programs can't set 110/134/150Bd and don't know RSVE/RS_Speed.
  564. (-- something untranslated --)
  565. Enter on all six places u if you don't have RSVE or RS-Speed.
  566. (-- something untranslated --)
  567.  
  568. DTR: (only for MFP.PRG)
  569. The DTR(data terminal ready)-signal is set at the start of this driver on 
  570. time to the value given here. Yes corresponds to on and is equivalent to 
  571. the behavior of TOS, No corresponds to off and prevents most modems from 
  572. going off hook before a communication program has been started.
  573.  
  574. RBL:
  575. Use 256 as a default. Here the receiver buffer length in byte can be set. 
  576. It may be in the range of 65534 (maximum) to 16 (minimum). Values out of 
  577. this range are set to the default of 256. The water marks are set to 1/4 
  578. (low water mark) and 3/4 (high water mark).
  579.  
  580. TBL:
  581. As RBL, but for the transmitter buffer length.
  582.  
  583.  
  584. Possible problems
  585. -----------------
  586. (-- something untranslated --)
  587.  
  588.  
  589. Function of ...
  590. ---------------
  591. See DRVIN.TXT, RSVE_COO.TXT, SERSOFST.TXT.
  592.  
  593.  
  594. Versions
  595. --------
  596. The data is valid for every MFP*.PRG if there is no special note.
  597. (-- something untranslated --, see German part)
  598. 1994-06-17  ATTENTION! Installation block adapted to MagiC3. Use together 
  599. only drivers and DRVIN from 1994-06-17 or younger. Older versions will not 
  600. run together with newer ones.
  601. 1994-08-18  FASTINT moved to DRVIN.PRG
  602. 1994-08-25  enhancement in bconout for MC68040 (Medusa)
  603. 1994-10-24  (-- something untranslated --, see German part)
  604. 1995-01-03  fast Bconmap parameter passing changed, ...
  605. 1995-02-02  new bug in Ring Indicator TIOCCTLGET removed (MFP.PRG, 
  606. MFP_BAST.PRG)
  607. 1995-06-26  bug removed ...
  608.